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The Examiner states that Ravi teaches a method for multimedia streaming as claimed in 
claim 1 . 

It is respectfully submitted that claim 1 includes the limitations of 

1) defining in a client in a multimedia streaming network at least one parameter for 
determining a rate adaptation operating range, wherein the streaming network comprises a server 
configured for providing streaming data to the client, the client having a receiver buffer for 
storing at least part of the streaming data to compensate for a difference between data 
transmission amount by the server and usage amount of the streaming data by the client so as to 
allow the client to have sufficient amount of streaming data to play out in a non-disruptive 
manner, and wherein the rate adaption operating range is used for rate adaptation between the 
server and the client; 

2) providing to the server information indicative of said at least one parameter; 

3) adapting in the server the data amount to a reception rate at the client based on said at 
least one parameter, wherein said adapting in the server comprises adjusting a sampling rate of 
the streaming data; and 

4) adjusting in the client packet transfer delay variation based on said adapting. 

In rejecting claim 1, the Examiner points to column 6, lines 33-47; column 7, lines 16-25 
and column 8, lines 26-45 to show that Ravi discloses adapting in the server the data amount to a 
reception rate at the client based on said at least one parameter, wherein said adapting in the 
server comprises adjusting a sampling rate of the streaming data. 

Applicant respectfully disagrees. 

At column 6, lines 32 to 47, Ravi discloses: 

The present invention is directed at the efficient and reliable streaming of data packets 

from stream server 220 to client computer 240, accomplished by optimally utilizing the 

bandwidth of the connection provided by computer network 290 while minimizing the loss 

of packets. In one embodiment, the transmission rate of the data stream is dynamically 

adjusted in response to changes in the bandwidth made available by computer network 

290 for the network connection between server 220 and client computer 240. 
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Accordingly, server 220, in response to feedback from client computer 240, dynamically 
selects transmission rates in order to better match the varying bandwidth capacity of the 
network connection. For example, server 220 streams video packets at 1 frames/second 
(fps), 5 fps, 10 fps, and 15 fps for bandwidths of 4 kbits/second (kbps), 14 kbps, 18 kbps, 
and 44 kbps. 

In the above paragraph, Ravi only discloses that the transmission rate of the data stream 
is adjusted in response to the changes in the bandwidth made available of the computer network 
between the server and the client. For example, the streaming can be carried out at 1, 5, 10 and 
15 fps for bandwidths of 4, 14, 18 and 14 kps. Ravi does not disclose or suggest that the server 
also adjusts the sampling rate of the streaming data. 

At column 7, lines 16 to 25, Ravi discloses: 

FIGS. 5 A, 5B, 5C, 5D and 5E, are detailed flowcharts illustrating steps 410, 420, 430, 
440 and 450, respectively, of FIG. 4. In step 410, the performance variables are 
computed. Next, in step 420, the computed performance variables are used to determine 
if it is desirable to decrease the bandwidth, and if so, then in step 430, the bandwidth is 
decreased. If a bandwidth decrease is not desirable, then in step 440, the performance 
variables are used to determine if it is desirable to increase the bandwidth. If a 
bandwidth increase is desirable, then in step 450, the bandwidth is increased. 

In the above paragraph, Ravi discloses the client computer 240 computes the performance 
variable (step 410), including computing playtime and delta_playtime (step 513); decreasing the 
bandwidth (step 430) and sending a reduce_bandwidth message to the server (step 537); or 
increasing the bandwidth (step 450) and sending an increase_bandwidth message to the server 
(step 522). According to Ravi, the term "bandwidth" is synonymous to the "transmission rate" 
(column 6, line 63 to column 7, line 5). This paragraph has nothing to do with the server. 

At column 8, lines 26 to 45, Ravi discloses: 
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FIG. 7 A is a flowchart illustrating the computation of variables Playtime and 
Delta JPlay time, step 513, in greater detail. In step 710, Playtime is set to the Duetime of 
the last packet in playout buffer 366. The computation of the Duetime is described in 
greater detail in step 740 below. Client computer 240 determines the change in the 
Playout _Buffer__Size (step 720). The Delta _Playtime is set to the difference between the 
current Playtime and the Playtime at the previous invocation of the Adjust _Bandwidth 
procedure (step 730). Variables Playtime and Delta Playtime provide exemplary absolute 
and relative measures, respectively, of the Playout _Buffer_Size, the number of data 
packet(s) in playout buffer 366. 

FIG. 7B illustrate the determination of the Duetime of a data packet (step 710). First, the 
BaseJTS is set to the timestamp of the first packet received by client computer 240 (step 
712). The BaseJTime is set to the time when the first packet was received (step 716). The 
TS is set the timestamp of the data packet of interest (step 746). 

In the above two paragraphs, Ravi only discloses how the client computers 240 computes 
the playtime and deltajslaytime (step 513, Figures 5 A and 7a). These paragraphs have nothing 
to do with how the server responds to the changes in the bandwidth made available of the 
computer network between the server and the client. 

On page 6 of the office action, first paragraph, the Examiner also states that Ravi teaches 
that the server, in response to the feedback from the client computer 240, dynamically selects 
transmission rates (streaming rates) in order to better match the varying bandwidth capacity of 
the network connection. Applicant respectfully agrees with the Examiner on this part. However, 
the Examiner fails to show that Ravi teaches adjusting the sampling rate. 

It is respectfully submitted that sampling rate is known as encoding rate at the server and 
the transmission rate is the rate at which the data packets are transmitted from the server to the 
client. Generally, the sampling rate and the transmission rate are different. That is why the 
client always has a buffer for "receiver buffering" in order to compensate for the difference 
between the encoding rate and the transmission rate. In particular, the client stores incoming 
data before passing the data to the media decoder for playout (see p.l of the specification). 



4 



944-001.108-1 



While Ravi discloses that the transmission rate is adjusted, Ravi does not disclose or suggest that 
the sampling rate is adjusted at the server. Thus, Ravi fails to disclose limitation No.3 in claim 1. 

For the above reasons, Ravi fails to anticipate independent claim 1 . 

For the same reasons, Ravi also fails to anticipate independent claims 1 1, 21, 26 and 32. 

As for claims 2-7, 9, 10, 12-17, 19, 20, 22-25, 27-31 and 36, they are dependent from 
claims 1, 1 1, 21, 26 and 32 and recite features not recited in claims 1, 1 1, 21, 26 and 32. For 
reasons regarding claims 1, 1 1, 21, 26 and 32 above, Ravi also fails to anticipate claims 2-7, 9, 
10, 12-17, 19, 20, 22-25, 27-31 and 36. 
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CONCLUSION 



Claims 1-7, 9-17 and 19-34 and 36 are allowable. Early allowance of all pending claims 
is earnestly solicited. 



Date: Lg^ . 1 » , 



WARE, FRESSOLA, VAN DER SLUYS 
& ADOLPHSON LLP 
Bradford Green, Building 5 
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Kenneth Q. Lao 
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